* New upstream release:
- fixes CVE-2026-33150, use-after-free vulnerability in the io_uring
subsystem,
- fixes CVE-2026-33179, NULL pointer dereference and memory leak in
fuse_uring_init_queue() .
Long Li [Wed, 16 Jul 2025 01:54:07 +0000 (09:54 +0800)]
[PATCH] memfs_ll: fix deadlock in truncate operation
Remove redundant mutex lock acquisition in the truncate() method to
prevent deadlock. The issue occurs when memfs_setattr() already holds
the mutex lock and then calls truncate(), which attempts to acquire
the same lock again.
Signed-off-by: Long Li <leo.lilong@huawei.com>
Gbp-Pq: Name memfs_ll-fix-deadlock.patch
This fixes commit 82bcd818
That commit had removed HAVE_LINUX_CLOSE_RANGE in meson generation,
but didn't remove the usage in fusermount.c - fusermount was then
not using the close_range syscall.
Closes: https://github.com/libfuse/libfuse/issues/1284 Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
Gbp-Pq: Name Fix-the-close_range-ifdef.patch
fuse_apply_conn_info_opts() was applying to 'want_ext',
which would cause conflicts with 'want' if the application
applied its own flags to 'conn->want'.
Solution is:
- to move fuse_{set,unset,get}_feature_flag and
convert_to_conn_want_ext() to fuse_lowlevel.c and
to define them as part of the public API, although
convert_to_conn_want_ext() should not be used - it is
currently needed to be a public function due as it needs
to be defined for the tests.
Related to https://github.com/libfuse/libfuse/issues/1171 and
https://github.com/libfuse/libfuse/pull/1172.
Closes: https://github.com/libfuse/libfuse/issues/1171 Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Gbp-Pq: Name Fix-fuse_apply_conn_info_opts.patch
[PATCH] meson.build: make special_funcs check more reliable
Unfortunately while cross-compiling with build tools like Buildroot it
happens to have repeated flags or anything that could lead to a warning.
This way the check fails because of a warning not related to the special
function. So let's use cc.links() and increase minimum meson_version to
0.60 since cc.links() has been added during that version.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name meson.build-make-special_funcs-check-more-reliable.patch
Checking for function "static_assert" : NO (cached)
Checking for function "pthread_setname_np" : NO (cached)
Check usable header "#include <linux/close_range.h>" : NO (cached)
These functions get now tested with compilation tests
and get found on my system.
Checking if "static_assert check" compiles: YES
Checking if "pthread_setname_np check" compiles: YES
Checking if "close_range check" compiles: YES
fuse_apply_conn_info_opts() was applying to 'want_ext',
which would cause conflicts with 'want' if the application
applied its own flags to 'conn->want'.
Solution is:
- to move fuse_{set,unset,get}_feature_flag and
convert_to_conn_want_ext() to fuse_lowlevel.c and
to define them as part of the public API, although
convert_to_conn_want_ext() should not be used - it is
currently needed to be a public function due as it needs
to be defined for the tests.
Related to https://github.com/libfuse/libfuse/issues/1171 and
https://github.com/libfuse/libfuse/pull/1172.
Closes: https://github.com/libfuse/libfuse/issues/1171 Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Gbp-Pq: Name Fix-fuse_apply_conn_info_opts.patch
[PATCH] meson.build: make special_funcs check more reliable
Unfortunately while cross-compiling with build tools like Buildroot it
happens to have repeated flags or anything that could lead to a warning.
This way the check fails because of a warning not related to the special
function. So let's use cc.links() and increase minimum meson_version to
0.60 since cc.links() has been added during that version.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name meson.build-make-special_funcs-check-more-reliable.patch
Checking for function "static_assert" : NO (cached)
Checking for function "pthread_setname_np" : NO (cached)
Check usable header "#include <linux/close_range.h>" : NO (cached)
These functions get now tested with compilation tests
and get found on my system.
Checking if "static_assert check" compiles: YES
Checking if "pthread_setname_np check" compiles: YES
Checking if "close_range check" compiles: YES
Direct leak of 352 byte(s) in 1 object(s) allocated from:
#0 0x7fbb19abf411 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7fbb1a0efd3b in fuse_fs_new ../lib/fuse.c:4814
#2 0x7fbb1a0f02b5 in fuse_new_31 ../lib/fuse.c:4913
#3 0x7fbb1a10ec5e in fuse_main_real ../lib/helper.c:345
#4 0x5625db8ab418 in main ../example/hello.c:176
#5 0x7fbb1983c78f (/usr/lib/libc.so.6+0x2378f)
SUMMARY: AddressSanitizer: 352 byte(s) leaked in 1 allocation(s).
```
That's because `fuse_lowlevel.c`s `fuse_session_destroy` would only call
the user supplied `op.destroy`, if INIT had been processed, but the high
level API relied on `op.destroy` to free `f->fs`.
This patch moves the freeing into `fuse_destroy` that will always be
called by our high-level API.
Gbp-Pq: Name Fix_memory_leak_in_high_level_API.patch
Sarath Lakshman [Sat, 11 Mar 2023 11:28:31 +0000 (16:58 +0530)]
[PATCH] Fix max_threads command line parameter propagation
The fuse_main_real() method doesn't apply the max_threads parameter
parsed through the commandline arguments. This commit fixes the wiring
of max_threads argument.
Gbp-Pq: Name Fix-max_threads-command-line-parameter-propagation.patch
[PATCH] upgrade of fuse_kernel.h based on Miklos expire_only kernel patch https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next&id=53e949edb7692dce02220eba926c9d75ecbb47f7
Gbp-Pq: Name revert_upgrade_of_fuse_kernel.h.patch
Direct leak of 352 byte(s) in 1 object(s) allocated from:
#0 0x7fbb19abf411 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7fbb1a0efd3b in fuse_fs_new ../lib/fuse.c:4814
#2 0x7fbb1a0f02b5 in fuse_new_31 ../lib/fuse.c:4913
#3 0x7fbb1a10ec5e in fuse_main_real ../lib/helper.c:345
#4 0x5625db8ab418 in main ../example/hello.c:176
#5 0x7fbb1983c78f (/usr/lib/libc.so.6+0x2378f)
SUMMARY: AddressSanitizer: 352 byte(s) leaked in 1 allocation(s).
```
That's because `fuse_lowlevel.c`s `fuse_session_destroy` would only call
the user supplied `op.destroy`, if INIT had been processed, but the high
level API relied on `op.destroy` to free `f->fs`.
This patch moves the freeing into `fuse_destroy` that will always be
called by our high-level API.
Gbp-Pq: Name Fix_memory_leak_in_high_level_API.patch
Sarath Lakshman [Sat, 11 Mar 2023 11:28:31 +0000 (16:58 +0530)]
[PATCH] Fix max_threads command line parameter propagation
The fuse_main_real() method doesn't apply the max_threads parameter
parsed through the commandline arguments. This commit fixes the wiring
of max_threads argument.
Gbp-Pq: Name Fix-max_threads-command-line-parameter-propagation.patch
[PATCH] upgrade of fuse_kernel.h based on Miklos expire_only kernel patch https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next&id=53e949edb7692dce02220eba926c9d75ecbb47f7
Gbp-Pq: Name revert_upgrade_of_fuse_kernel.h.patch
projects / fuse3.git / log